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Abstract 

In this work we describe, design and analyze the se- 
curity of a tamper-evident, append-only data struc- 
ture for maintaining secure data sequences in a 
loosely coupled distributed system where individ- 
ual system components may be mutually distrust- 
ful. The resulting data structure, called an Authen- 
ticated Append-Only Skip List (AASL), allows its 
maintainers to produce one-way digests of the entire 
data sequence, which they can publish to others as 
a commitment on the contents and order of the se- 
quence. The maintainer can produce efficiently suc- 
cinct proofs that authenticate a particular datum 
in a particular position of the data sequence against 
a published digest. AASLs are secure against tam- 
pering even by malicious data structure maintain- 
ers. First, we show that a maintainer cannot "in- 
vent" and authenticate data elements for the AASL 
after he has committed to the structure. Second, 
he cannot equivocate by being able to prove con- 
flicting facts about a particular position of the data 
sequence. This is the case even when the data se- 
quence grows with time and its maintainer publishes 
successive commitments at times of his own choos- 
ing. 

AASLs can be invaluable in reasoning about the 
integrity of system logs maintained by untrusted 
components of a loosely-coupled distributed sys- 
tem. 

1 Introduction 

Dependable systems rely heavily on logs of 
data, system events, transactions, and security 
decisions. Inspecting such logs while the sys- 
tem is running (on-line) or after an exceptional 
event has caused the system to cease opera- 



tions (off-line) can help maintain accountabil- 
ity through audit trails, repair failures through 
undo/redo logs, and improve performance via 
profiling. 

In distributed systems, especially those in- 
tended for loosely-coupled communities of in- 
dependent components (generally called peer- 
to-peer systems), it is frequently infeasible to 
maintain a central system log; in fact, often 
there is no central authority that can be trusted 
by all participating components to maintain a 
log faithfully. Instead, each component stores 
its own log of events observed locally, or of in- 
teractions with other components. The log for 
the entire system does not exist physically; it 
is made up of log fragments scattered around 
different system components. 

These distributed log fragments must be pe- 
rused for answers when a failure occurs or a 
component is reported as misbehaving. For ex- 
ample, consider a distributed file system, where 
component A requests that component B store 
datum d and B accepts. Later A attempts to 
retrieve datum d from B and B denies having 
this datum. A can convincingly accuse B of 
misbehavior only if it can show that, at first, 
B agreed to hold d and, later, B denied having 
done so. 

In such a setting, logs can be a very sensi- 
tive and vulnerable system resource. A com- 
ponent, along with the entity that operates it, 
cannot trust another component to retain the 
order of its locally logged events or to refrain 
from changing events after it has logged them. 
This prevents A, in the example above, from us- 
ing S's log to justify its accusation. Similarly, 
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an arbiter must be skeptical of an accusation 
made by A that relies on the integrity of A's 
log. 

The problem has been addressed in the lit- 
erature via the use of collision-resistant hash 
functions to link the contents of earlier log en- 
tries to later ones [4, 5, 8, 9]. The collision- 
resistance property of the hash functions used 
makes it very difficult to "rewrite history" in a 
sensitive log, without causing dramatic changes 
in the entire log. However, with very few ex- 
ceptions (notably, work by Buldas et al. [2]), 
no attention has been paid to the scalability 
of such hash-based techniques when logs grow 
very long and interesting sensitive log entries 
may have been created years — and billions of 
log entries — ago. 

In this paper, we analyze the security of the 

Authenticated Append-only Skip List (AASL). 
The AASL is a novel data structure that is de- 
signed for the efficient maintenance of and ac- 
cess to very large, tamper-evident sequences of 
data. AASLs provide a mechanism for detect- 
ing structural corruption, such as modification, 
removal or reordering of data, whenever those 
data are accessed. We have used AASLs in 
Timeweave [5], a mechanism that allows com- 
ponents of a distributed system to maintain a 
local trustworthy view of a global system log. 

A distributed system component that main- 
tains an AASL can compute succinct one-way 
digests of the entire structure; these digests 
can serve as a commitment on the data struc- 
ture contents and order, and can be conveyed 
to other system components as such. A re- 
mote component wishing to establish whether 
a particular datum appears in such a data se- 
quence (membership) can request a proof from 
the maintainer of the AASL. This proof can be 
verified against the digest to which the main- 
tainer has committed. 

AASLs are guaranteed to prevent maintain- 
ers from proving conflicting facts about a data 
sequence, even at different points in the evolu- 
tion of the sequence over time. In this paper, we 
describe the construction of AASLs and prove 
the security guarantees they offer. 



2 Background 

In this section, we describe related work that 
protects sensitive logs from tampering, and re- 
lated work on securing the contents of skip lists. 

The integrity of public logs or commit- 
ment sequences has traditionally been pro- 
tected through the use of one-way hash func- 
tions. Spreitzer et al. [9] describe how to pro- 
tect the modification order of a weakly consis- 
tent, replicated data system, by placing succes- 
sive write and read operations in a hash chain; 
this is a linked list, where every clement is an- 
notated with a label computed by hashing to- 
gether the value of the element and the label of 
the preceding element. Schneier and Kelsey [8] 
propose a historic integrity scheme for logs of 
untrustcd or vulnerable machines. Their work 
protects access-controlled log entries against 
tampering or unauthorized retroactive disclo- 
sure through hash chaining. In secure digital 
time stamping [4], a digital notary places docu- 
ments in a hash chain, so as to be able to derive 
temporal precedences between document com- 
mitments. 

Unfortunately, reasoning about simple hash 
chains can be very expensive when they grow 
long. To check that a particular element occu- 
pies the beginning of the chain, all the hashes 
between that element and the end of the chain 
must be performed. Buldas et al. [2] improve 
greatly on this linear cost; they describe opti- 
mally efficient hash graphs that permit the ex- 
traction of such temporal precedences with op- 
timal proof sizes, on the order of the logarithm 
of the size of the graph. 

Goodrich et al. [3] retrofit skip lists for 
tamper-evidence. In that work, the authors 
propose an authenticated skip list that relies 
on commutative hashing. Anagnostopoulos et 
al. [1] extend this construct to deal with per- 
sistent data collections, where older versions of 
the skip list are available, and they are each, by 
themselves, an authenticated skip list. How- 
ever, these structures are not designed to be 
append-only. As a result, they are not well- 
suited for tamper-evident logs: a malicious 
maintainer can remove and then reinsert ele- 
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merits from the "middle" of the structure across 
version changes. A verifier must check vigi- 
lantly that a log entry that interests him re- 
mains consistently in every new version of the 
structure produced by the maintainer, which 
can be very expensive when versions are pro- 
duced frequently. 

We have used the structure described in this 
paper in previous work [5] to preserve the his- 
toric integrity of a loosely coupled distributed 
system. Here we focus on a detailed design 
and analysis of the security guarantees that the 
structure offers. 

3 Design 

An Authenticated Append-only Skip List 
(AASL) is a data structure conceptually based 
on skip lists [7]. Skip lists are sorted linked 
lists with extra links, designed to allow fast 
lookup of the stored data elements by taking 
"shortcuts." The basic idea is to enhance linked 
lists, which connect each element in the data se- 
quence to its successor, by also linking some ele- 
ments to successors further down the sequence. 
Roughly half of the elements have links to their 
two-hop successor, roughly a quarter of the el- 
ements have links to their four-hop successor, 
and so on. As a result, during traversal from 
element a to element b, the traversal path fol- 
lows repeatedly the longest available link from 
the current element that does not overshoot the 
destination b, and thereby reaches b in fewer 
steps than would be possible by just travers- 
ing every intervening element between a and b. 
Skip list traversals achieve logarithmic traver- 
sal path lengths in the number of data elements 
in the structure, as opposed to the linear paths 
offered by regular linked lists. 

3.1 AASL construction 

AASLs take advantage of the shortcut idea, de- 
scribed above, albeit in a deterministic fash- 
ion as opposed to the randomized nature of the 
original skip lists. AASLs of n elements consist 
of log2 n coexisting linked lists, each designated 
by a different level number. The linked list at 




Figure 1: An example of a deterministic skip 
list, containing 10 data elements. Boxes denote 
element positions (indices), and circles denote 
the actual element data. We represent the skip 
list as an overlapping set of linked lists, each 
at a different level. Pointers are marked with 
the level of the linked list to which they belong. 
The thick gray line outlines a traversal of the 
skip list, from the 3rd to the 7th element. 

level is a regular linked list connecting all el- 
ements in the data sequence. The linked list at 
level 1 is a linked list that only contains every 
other element from the original data sequence. 
The linked list at level / contains every 2'-th el- 
ement of the original data sequence. Element i 
belongs to the Z-level linked list if and only if i 
is divisible by 2K Figure 1 illustrates this basic 
structure. 

AASL elements, in addition to their datum 
and their index number, carry an authenticator. 
The authenticator T* for the i-th element is a 
value derived via a few applications of a one- 
way hash function h, such as SHA-1 [6], to the 
datum di of the z-th element and the authen- 
ticators of the immediate predecessors of that 
element on each of the linked lists in which it 
appears. 

More specifically, an authenticator is com- 
puted in two steps (see Figure 2). First, the 

partial authenticators for an element are com- 
puted, one for each list in which that element 
participates. A partial authenticator is a value 
computed by hashing together the current in- 
dex number, the current datum, the CTirrent list 
level, and the authenticator of the preceding el- 
ement on that list. The partial authenticator 
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Figure 2: An illustration of the construction of 
the skip list authenticators for elements 9 and 
10. The construction of the 8-th authenticator 
is not shown. 



Algorithm 1 SingleHopTraversalLevel 
{i,n) /. Return the highest linked list level I 
that must be followed in the AASL from element i 
to ckinicnt n, where i > n. 
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1^0 

while 2' divides i do 
if 2 + 2' < n then 

L <— / {L-hop does not overtake n.} 
else 

Return L {Last safe hop level.} 
end if 
l^l + l 
end while 

Return L {The highest level possible for i.} 



for the element in position i on the list at 
level I is computed by 

L\ = hmdi\\r-^') (1) 

where II denotes bit-string concatenation. Sec- 
ond, the partial authenticators are combined, 
again using the hash function, to produce the 
element authenticator. The authenticator of 
the i-ik element is computed by 

r = h{L'A\L]\\...\\Lf^) (2) 

where /j is the highest level of linked list in 
which the i-ik element appears, fi is defined 
by the relation 

/. = {„:z = 2"rAgcd(2,r) = l} (3) 

A very useful property of skip lists is that 
they can be traversed from a source element i 
to a destination element n (z > n) in a num- 
ber of steps that is logarithmic in the elements 
of the structure. At every step, a linked list 
at the highest level is picked, among those in 
which the current element participates, so as 
to travel the farthest distance towards the des- 
tination, without overtaking it. Algorithm 1 
specifies how a single hop is chosen for such a 
traversal. The thick gray line in Figure 1 illus- 
trates a traversal of the structure. 

3.2 AASL Membership Proofs 

The primary use of AASLs is to support au- 
thenticated answers to membership questions, 



such as "what is the 7-th clement in the 
AASL?", while maintaining the append-only 
property of the AASL. To accomplish this func- 
tionality, it is important, first, that the party 
asking the question (the verifier) know in which 
AASL she is asking that question; and, sec- 
ond, that once the verifier receives a response, 
she holds that response as unequivocal for the 
AASL in question. 

An AASL is uniquely determined by a digest. 
This is the authenticator of the last appended 
element into the structure. The maintainer of 
an AASL conveys this short value to potential 
verifiers as commitm.ent to the exact contents 
of the AASL. A verifier who receives such a di- 
gest verifies all subsequent exchanges with the 
maintainer against this digest. 

A response to a membership question on the 
contents of an AASL consists of a membership 
claim and a membership proof. A membership 
claim has the form "Data element d occupies 
the i-th position of the AASL whose n-th au- 
thenticator is known to the verifier," and is 
denoted by {i,n,d). The corresponding mem- 
bership proof is denoted by This proof 
convinces the verifier that, first, the maintainor 
had decided what the i-th value d would be be- 
fore issuing the n-th authenticator; second, the 
maintainer cannot authenticate any other value 
d' ^ d as the value of the z-tli clement of the 
AASL with the known n-th authenticator T. 

The AASL maintainer constructs the mem- 
bership proof ii^*'"''^ by traversing the AASL 
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from the i-th. to the n-th element, hop by 
hop, as described by SingleHopTraversal- 
Level. For every encountered skip hst ele- 
ment j, the maintainer constructs a proof com- 
ponent that consists of the j-th data el- 
ement and the authenticators of its predeces- 
sors on all the linked lists in which it appears: 
= {dj; ■.0<l<fj)). The sequence 

of all proof components makes up the member- 
ship proof E'^''-'^ = {C^ : j G 5^'"), where S^'" 
is the sequence of elements traversed from i to 
n. The appendix contains Algorithm 6, which 
describes the construction process for a single 
proof component, and Algorithm 7, which out- 
lines the overall proof construction process. 

The verifier processes a membership proof 
against the AASL authenticator that it holds 
to verify the validity of a membership claim. 
The verification process mimics the proof con- 
struction process. The verifier's job, however, 
is to make sure that the purported proof is 
well-formed and yields the known authentica- 
tor starting with the element datum and posi- 
tion in the maintainer's membership claim. The 
verification may succeed with a positive result, 
which means that the claim is true; it may suc- 
ceed with a negative result, which means that 
the claim is false, i.e., it cannot be true; and it 
may fail, in which case nothing is known about 
the claim, except that the supplied proof is in- 
appropriate for the given claim. 

For every element j in the traversal from the 
i-th to the n-th element, the verifier checks that 
the corresponding component C in the proof 
is formed as component should be formed; 
he then uses that component to compute what 
the j-th authenticator should be based on that 
component. Furthermore, since, during traver- 
sal, the authenticator of a traversed element is 
always used in the computation of the authenti- 
cator of the next traversed element, the verifier 
must check that the authenticators it computes 
in earlier steps of the verification process are 
consistent with those used in later verification 
steps. Finally, the proof must be checked for 
applicability, that is, it should match the claim 
it purportedly proves: if a membership proof 
claims to prove the membership claim {i,n,d), 



then the datum in the first proof component 
should be d. 

Algorithm 2 details how a single proof com- 
ponent is handled by the verification pro- 
cess. Algorithm 3 details the overall proof 
verification process, making use of the single- 
component proof verification from Algorithm 2. 

Algorithm 2 ProcessProofComponent 
(j, C) => T. Process the proof component C that 
corresponds to the j-th element in an AASL, and 
return the rcsTilting j-th AASL authenticator. 

1: (d; (To, Ti,..., )) {Parse C.} 

2: \f F ^ then 

3: Proof component is invalid 

4: end if 

5: P ^ 

6: for / = to F do 

7: h{j\\l\\d\\Ti) {Calculates ^. If the proof 

is correct, then T; must be T-*"^ in the orig- 
inal AASL.} 

8: P^P\\L 

9: end for 

10: T h{P) {Should calculate T^.} 
11: Return T 



Section 4 proves the security properties of 
AASLs, as described informally above. Namely, 
given an AASL digest known to verifiers who 
follow ProcessMembershipProof, the main- 
tainer can only authenticate a single, unique 
membership claim per element to any of those 
verifiers, and he can determine that digest only 
after he has decided which claims he wishes to 
authenticate. 

3.3 AASL Evolution 

AASLs are useful in distributing the contents 

of fixed-forever data sequences, but can be in- 
valuable in distributing the contents of data se- 
quences that grow over time. In this section 
we address how AASLs can be used when the 
data sequences on which they are based evolve 
over time, especially when the verifier needs to 
access the sequence as it changes. 

As new elements are appended to a data se- 
quence that a maintainer keeps in an AASL, the 
AASL grows with new authenticators for the 
new elements. Whenever it is necessary to com- 
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Algorithm 3 ProcessMembershipProof 

{i,n,d,T,E) =^ TRUE/ FALSE. Process the 
membership proof E of the membership claim 
{i,n,d) against authenticator T. 
1: (Ci,C2,...,Cs) {Parse £".} 

2: Tcur PROCESSPROOfCOMPONENT (i,Ci) 

{Should calculate T\} 

■->• prev ^ cur 

4: / <— SingleHopTraversalLevel (i,n) 

c <— 2 {Component counter.} 
while J < n do 

Tcur <— ProcessProofComponent (j, Cc) 
{Should return .] 
9: (d';(To,ri,...,Tf)) 
if T; ^ Tprev then 

Proof is invalid {The values for the same 
authenticator computed in the previous 
step and included in the current compo- 
nent differ.} 



10: 
11 



12: end if 

13: Tpj-Qu < Tcy^j- 

14: I ^ SingleHopTraversalLevel (j, n) 

15: 3^3 + 2' 

16: 

17: end while 
18: if 5 7^ c then 

19: Proof is invalid {Wrong number of proof com- 
ponents.} 
20: end if 

21: if Tcur 7^ T then 

22: Proof is invalid {The T" just computed from 

the proof is different from the T" known.} 
23: end if 

24: (d'; (. . .)) <— Ci {Parse the datum in the first 
component.} 



25 
26 
27 
28 
29 



if d = d! then 
Return TRUE 

else 

Return FALSE 

end if 



mit to newer versions of the AASL, the main- 
tainer updates verifiers with the new AASL di- 
gest, i.e., the currently last AASL authentica- 
tor. In addition to the security guarantees de- 
scribed in the previous section, verifiers of a dy- 
namic AASL must also be convinced that mem- 
bership claims they verified in previous versions 
of the AASL remain true in the new version. 
Simply, the AASL maintainer must be Tinable 
to "rewrite history" to which he has committed 
in the past when he advances to a new version 
of the structure. 

The preservation of AASL history is sup- 
ported by an advancement proof, which accom- 
panies the new digest in an AASL version up- 
date. An advancement proof is very similar to a 
membership proof. Intuitively, an advancement 
proof authenticates a membership claim about 
an authenticator, instead of a data value. We 
call this an advancement claim; it has the form 
^'Tprev is the i-th authenticator of the AASL 
whose n-th authenticator is Tnew" 

Because advancement proofs are basically 
membership proofs, their construction is al- 
most identical to membership proof construc- 
tion, and their components have the same form. 
Advancement proof from the i-th to the n- 
th AASL authenticator is the same as member- 
ship proof without the first proof compo- 
nent. The first proof component of a member- 
ship proof computes the authenticator of the 
source element from the element datum and 
earlier AASL authenticator s; this step is un- 
necessary when the source element authentica- 
tor is already known, as is the case with ad- 
vancement. In the appendix, we outline the 
advancement proof construction algorithm (Al- 
gorithm 8). Figure 3 illustrates an example of 
advancement. 

A verifier need remember three pieces of in- 
formation for a given remote dynamic AASL: 
the latest AASL size n, the latest digest T, and 
a vector of earlier authenticators called a basis. 

The basis vector is used to check consistency 
among the values of "reusable" authenticators 
included in different advancement proofs for the 
same AASL. Reusable authenticators are those 
AASL authenticators that may appear again in 
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Figure 3: An example of advancement in a dy- 
namic AASL. In version 1, the AASL has ele- 
ments 1 through 9. The corresponding advance- 
ment proof from the empty AASL to version 1 is 
= ((4;(T^T^T^T0)),(d9;(^8))). Then 
the maintainer adds element 10 and publishes 
version 2, with advancement proof A^'^^ = 
{{dio'i The gray links delineate the 

traversal paths that the two advancements take. 

subsequent advancement proofs for the AASL. 
In the appendix, we illustrate an example of 
cheating that a malicious AASL maintainer can 
perpetrate when he is free to use inconsistent 
values for such reusable authenticators across 
advancements. 

The structure of a basis vector resembles the 
binary representation of the AASL element in- 
dex to which it corresponds. Specifically, basis 
for element z is a vector of I authenticators, 
where I = [log2 ij is the number of significant 
bits in the binary representation of i. The vec- 
tor contains a special "empty" value in those 
positions in which the binary representation of 
i contains a 0; the rest of the basis vector's 
positions are occupied by authenticator values. 
These authenticator values correspond to the 
authenticators of the elements encountered in 
the traversal of the AASL from element to ele- 
ment i. A traversal from to z proceeds in hops 
of decreasing length, starting with the largest 
power of 2 that is less than or equal to the des- 
tination. For example, for destination 9 (binary 
1001), the traversal from first hops over 8 = 2^ 
elements to element 8, and then over one last 
element (2'^) to clement 9 (see Figure 3). In the 
associated basis B'^, each non-zero "bit" posi- 



tion is annotated with the authenticator of the 
element from which the corresponding traver- 
sal hop launches, that is B^ = {T^,0,0,T^). 
The basis B^ for the 0-th element (the initial 
value of the AASL) contains no values. Note 
that verifiers need not remember bases for a 
static AASLs, since the concept of advancement 
is meaningless in those. 

Advancement proof verification occurs in two 
phases. First, the verifier checks whether the 
last digest he holds can appear in the AASL 
of the new digest. This check is almost iden- 
tical to the verification of membership proofs, 
as described in Section 3.2, with the exception 
that what is verified is the membership of an 
authenticator, not a datum, in the AASL. 

The second phase of checking an advance- 
ment proof deals with the basis. For every 
component in the proof, the authenticators in- 
cluded therein are checked against the values 
of any corresponding authenticators in the ba- 
sis. If the component is consistent with remem- 
bered authenticator values, the basis is updated 
with any reusable authenticators seen first in 
the component. In the end, the basis is up- 
dated to reflect the newly acquired digest and 
advancement proof. Algorithm 4 provides the 
details, and is reminiscent of binary addition of 
positive integers. 

ProcessAdvancementProofComponent is 
invoked once for every component in the ad- 
vancement proof, after that component has 
been processed as a membership proof compo- 
nent. Algorithm 5 describes how the whole ad- 
vancement proof verification proceeds. 

A powerful use of AASLs is to determine the 
possible relative orders of insertion of different 
data in the maintainer's tamper-evident data 
sequence. For example, let Molly by an AASL 
maintainer who claims that she did not learn 
value a until after she had committed to value 
b. If verifier Van holds valid proofs of the mem- 
bership claims {i,j,a) and {k,n,b) in Molly's 
AASL, where i < j < k < n, then he can con- 
vince anyone who agrees on Molly's j-th and n- 
th AASL authenticators that she is lying; Molly 
must have known value a before her commit- 
ment to the j-th authenticator, and therefore 
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Algorithm 4 ProcessAdvancementProof- 
COMPONENT {j,T,B,C,l) =^ B' . Process an ad- 
vancement component C that takes a hop of level 
I from the j-th digest T with basis B. Return the 
new basis. 
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(d; (To, Ti, . . . ,Tf)) ^ C {Parse C.) 



\i F ^ fj then 

Proof component is invalid {The component 
contains the wrong number of authentica- 
tors.} 
4: end if 

5: {Bq, . . . , Bh) <— B {The values in the basis vec- 
tor.} 

if Bi = then 
Bi^T 

Return {Bq, . . . ,Bb) 
else 

c <— I {Current basis element.} 
w^hile Be ^ do 
if Be ^ Tc+i then 

Advancement is invalid. {The main- 
tainer is now sending a different value 
(Tc+i) for an authenticator whose value 
he reported as Be before.} 
14: end if 
15: carry ^ Be 

16: Be^ 
17: 

18: end while 

19: Be <— carry 

20: Return {Bq, .... -B„iax{b,c}) {The vector may 

have grown by one non-empty element.} 

21: end if 



Algorithm 5 ProcessAdvancementProof 

(z, 71, Tp-pey , Bpfev: "Fyiew : ^new Proccss the ad- 
vancement proof A that establishes Tnew as the n-th 
authenticator, starting with the i-th authenticator 
Tprev and basis Bprev ■ The process returns the new 
basis Bnewi if successful. 

1: {C2, ■ ■ ■ ,Cs) ^ A {Parse A. The numbering 
starts with 2, to be consistent with the num- 
bering in ProcessMembershipProof.} 

2: c ^ 2 {Component counter.} 

3: J ^ I 

4: while i < n do 

5: I ^ SingleHopTraversalLevel (j, n) 
6: Bnew <— ProcessAdvancementProof- 
COMPONENT {j, Tprev, Bprev, Ce, I) {This re- 
turns 5^+2'.} 
7: j ^ j + 2' {Next element in traversal.} 

8: Tcur ^ PrOCESSPROOFCOMPONENT (j, Ce) 

{Should be TK} 
9: {d; (To, Ti, . . . , T^)) ^ Ce {Parse Ce-} 

if Ti ^ Tprev then {Tprev should be TJ-2'.} 
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12 
13 
14 
15 
16 
17 
18 



Proof is invalid {The value of T^ ^ com- 
puted in the previous step is not the same 
as the value for T^~'^ in the current proof 
component.} 
end if 



± p. 
B„ 



T 

- Br, 



'prev ^ 
C^C+1 

end while 
if 5 ^ c then 

Proof is invalid {Wrong number of proof com- 
ponents.} 
19: end if 

20: if Teur ^ Tr,ew then 

21: Proof is invalid {The T" claimed by the ad- 
vancement is different from the one computed 
by processing the advancement proof.} 

22: end if 

23: Return Bnew 
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before her commitment to b. Such temporal or- 
derings can apply also to the data themselves, 
when those data contain a "freshness marker" , 
as is the case, for example, with signed state- 
ments containing a nonce. We detail how tem- 
poral ordering in a distributed log can be pre- 
served in the Timeweave project [5]. 

In the next section, we prove the security 
properties of static AASLs, described in Sec- 
tion 3.2, and of dynamic AASLs, described in 
this section. 

4 Security Analysis 

In this section, we substantiate the security 
guarantees that AASLs offer to their users. Our 
goal is to secure the "commitment metaphor" of 
AASLs for verifiers who follow the membership 
and advancement proof verification procedures 
described in the previous section. Informally, 
this means that, first, diligent verifiers accept 
only a single, unique membership claim for ev- 
ery position in the data sequence on which an 
AASL is built; second, the data structure main- 
tainer must decide which membership claims he 
can prove before he commits to the AASL by 
giving a digest to potential verifiers. 

There are two distinct "roles" that a mali- 
cious adversary can take, with regards to an 
AASL. On one hand, the adversary may be an 
eavesdropper, who wishes to prove to a verifier 
a false membership claim of his choosing, for 
an AASL that he does not maintain. On the 
other hand, the adversary may be the AASL 
maintainer, who wishes either to defer choosing 
to which membership claim to commit until af- 
ter he has apparently committed; or to prove 
confiicting membership claims to different veri- 
fiers (a membership claim (i, n, d) conflicts with 
membership claim {i,n',d') if d d'). A mali- 
cious AASL maintainer is a more powerful ad- 
versary, because he can use arbitrary means to 
produce a digest before he has to relay it to po- 
tential verifiers. In what follows, we prove that 
AASLs are resistant to such attacks. 

First, we show that an adversary is unable to 
construct convincing membership proofs (that 



he has not already seen) from a random AASL 
digest. This prevents a malicious eavesdropper 
from proving false membership claims. This 
also prevents a malicious AASL maintainer 
from committing to bogus digests and only de- 
ciding later what to prove to its unsuspecting 
verifiers. This property is similar to the pre- 
image resistance property of one-way functions. 

Theorem 1 (AASL Membership Proof 
Pre- image Resistance). Consider randomly 

chosen T from the set of values of the hash 
function h. A computationally hound adversary 
cannot construct efficiently an AASL member- 
ship proof of any datum d in position i of 
an n-element AASL, for any i and n (0 < i < 
n). 

This result follows directly from the pre- 
image resistance of the hash function h. 

Suppose the adversary can pick d, i and n 
and construct a membership proof E)*'"'*^ of d 
in position i, where T is the given n-th authen- 
ticator, so that a verifier in possession of T and 
following Algorithms 2 and 3 accepts the proof. 

Given £;*'"'<^, i, d, n and T, Algorithm 3 exe- 
cuted by the verifier must fail to match the con- 
dition of Line 21. This means that in the last 
iteration of Line 8, Tcur returned from Algo- 
rithm 2 must be the random T given to the ad- 
versary in the challenge. However, this means 
that, in Line 10 of Algorithm 2, the adver- 
sary must be able to find a pre-image of the 
pre-image resistant hash function h for random 
image T. As a result, the hypothesis is false, 
and the adversary cannot produce a pre-image 
proof. □ 

Theorem 1 only deals with cheap, unsophis- 
ticated malice. We proceed by addressing more 
sophisticated attacks that rely on the manipu- 
lation of corrupt AASLs by their maintainer or 
on the manipulation of observed proofs by an 
eavesdropper. There arc three types of such at- 
tacks. First, the adversary can modify correct 
proofs to make them prove a false membership 
claim. Second, the maintainer can produce an 
AASL digest against which he can prove con- 
flicting membership claims. Third, the main- 
tainer can produce AASL digests and advance- 
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ment proofs so as to prove conflicting mem- 
bersliip claims against different versions of the 
AASL. We call the first two attacks second pre- 
image and collision, respectively. We call the 
third attack evolutionary collision, because it 
relies on subverting AASL evolution across ver- 
sions. 

In the next theorem, we prove that AASLs 
are resistant to the second type of attack, col- 
lision attacks (Theorem 2). AASLs arc also re- 
sistant to the first type of attack, second pre- 
image, but the proof is a direct corollary of col- 
lision resistance, so we defer to the Appendix 
for it (Theorem 4). 

Theorem 2 (AASL Membership Proof 
Collision Resistance). A computationally 
bound adversary cannot construct two member- 
ship proofs E and E' verifiable against the same 
authenticator T that authenticate different data 
values in the same sequence position. 

Suppose that an adversary can, in fact, con- 
struct an efficient proof collision with proofs E 
and E' against common authenticator T. Let 
the two membership claims he t = {i,n,d) and 
t' = {i,n',d'), respectively (t 7^ t'). We trace 
ProcessMembershipProof backwards for both 
proofs E and E' in parallel, and reach a viola- 
tion of the one-way properties of the hash func- 
tion h. 

Since both membership proofs can be verified 
against the same authenticator T (which corre- 
sponds to a purported AASL's n-th element in 
the case of E and a different purported AASL's 
n'-th element in the case of E'), in the last it- 
eration of Line 8 of Algorithm 3, the invocation 
of Algorithm 2 must yield the same result T. In 
this last iteration, local variable j, the current 
element of the purported AASL, is equal to n 
and n', respectively. 

However, this means that the adversary must 
be able to cause the verifier to invoke Pro- 
cessProofComponent with input (n, C) and 
{n', C) but receive the same result T for both 
invocations. This is equivalent to passing to 
Equations 1 and 2 different i's and T's but cal- 
culating the same T*. Intuitively, since the 
two equations use a one-way hash function. 



this should be impossible, i.e., ProcessProof- 
COMPONENT should Only return the same result 
when invoked with identical inputs (we prove 
this rigorously in the Appendix, in Lemma 1). 
Therefore, in the last iteration ProcessProof- 
CoMPONENT can only be invoked with (n, C) 
and (ra', C) li n = n' . This restricts our as- 
sumed proof collision to support membership 
claims that only differ in the data values d and 
d'. 

Since both proofs authenticate position i in 
an n-length AASL, Line 18 of ProcessMem- 
bershipProof imposes that the proof lengths 
must be equal to the same S. We prove induc- 
tively on the number of components in the two 
proofs that the two proofs must be identical. 
Induction follows the iterations of the loop in 
ProcessMembershipProof, Lines 7 - 17, from 
last iteration to first. 

The base case for the last components Cg and 
C'g, respectively, follows directly from the col- 
lision resistance claim of ProcessProofCom- 
PONENT (Lemma 1 in the appendix) and from 
the supposition that both proofs are verifiable 
against the same authenticator T. 

To establish the inductive step, consider the 
c-th proof components Cc and C'^ of the two 
membership proofs and assume they are equal. 
In the associated loop iteration in Process- 
MembershipProof, Line 9 extracts the individ- 
ual F hash values of the c-th proof component; 
these are pairwise equal across the two respec- 
tive proof components, since the components 
themselves are equal. The Z-th of these hash 
values must be equal to the value of the respec- 
tive Tprev, in Line 10. Since the Z-th hash values 
are equal across proofs, the values of T^^ev are 
the same in the invocations of ProcessMem- 
bershipProof for the two membership proofs. 
But, in the previous loop iteration, in Line 13, 
Tprev had been assigned the value of the re- 
spective Tcur, computed using ProcessProof- 
CoMPONENT in Line 8. Because of the colli- 
sion resistance of ProcessProofComponent, 
this means that the inputs to the two respec- 
tive invocations of ProcessProofComponent 
must also be identical in that loop iteration, 
which means that the (c — l)-st element com- 
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ponents Cc-i and C^_i, respectively, are also 
identical. This proves the inductive step. 

The induction applies to all but the first 
proof components in the two proofs, which are 
processed outside the loop of ProcessMember- 
shipProof, in Lines 2-5. The same argu- 
ment as the inductive step above can also be 
applied here: the Tcur returned by the respec- 
tive invocations of ProcessProofComponent 
on the respective first proof components is the 
same Tp^ev that ends up matching the identical 
Z-th hash values of the respective, equal second 
proof components in Line 10 of the first loop it- 
eration. Consequently, the respective first proof 
components must also be equal. 

We have shown that two proofs E and E' au- 
thenticating the same element position i against 
the same authenticator T must be identical. 
But in ProcessMembershipProof, Line 25, 
the datum in the first component of a proof 
must match the one whose membership is ver- 
ified. This contradicts the collision hypothesis, 
because the condition in Line 25 only succeeds 
if the algorithm is invoked with the data value 
that occupies the first proof component of the 
two proofs, d and d' cannot be different. □ 

Finally, we prove that AASLs are resistant to 
the third type of malicious manipulation attack, 
evolutionary collision, in Theorem 3. AASLs 
have the property of evolutionary collision- 
resistance if it is impossible for a computation- 
ally constrained adversary to produce advance- 
ments and membership proofs that authenti- 
cate two different data elements d and d' ^ d 
for the same position i, in any version of the 
same AASL. 

The definition is fairly broad in scope: it 
covers unrelated, mutually unknown verifiers A 
and B, who, through different sequences of ad- 
vancements, arrive at the same digest T for po- 
sition n of an AASL at different times; a mali- 
cious provcr must be unable to convince A that 
d is at position i and convince B that d' ^ d 
is at position i, even in different versions of the 
AASL in its separate evolution paths towards 
length n and digest T. 

Two advancements A^'^ and A^'^ are con- 
nected if the source element of the latter ad- 



vancement is the destination clement of the for- 
mer, that IS j = k. In what follows, we refer 
to a sequence of connected advancements as an 
advancement sequence, and the sequence of ele- 
ment positions traversed by that advancement 
sequence as an advancement path. In a simi- 
lar manner, we define the sequence of element 
positions traversed by a membership proof as a 
membership proof path. 

Our proof strategy for evolutionary collision 
resistance is to show that if two diligent veri- 
fiers have both accepted the same authentica- 
tor for the same AASL clement, they must ar- 
rive at the same value for the authenticators of 
some other strategic AASL elements. Namely, 
we show that the two verifiers must "agree" 
on the authenticators they compute during the 
processing of the membership proofs with which 
the adversary seeks to fool them. From Theo- 
rem 2, if two verifiers agree on the authentica- 
tors computed during membership proof veri- 
fication, they cannot be verifying the truth of 
conflicting membership claims. 

To reduce authenticator agreement during 
the verification of independent advancement 
paths to authenticator agreement during the 
verification of independent membership proofs, 
we use two "authenticator agreement claims," 
which we describe here informally, but prove 
rigorously in the Appendix. 

First, if a membership proof verification and 
an advancement proof verification agree on the 
value of a particular AASL authenticator, then 
they must also agree on the authenticator val- 
ues of all earlier AASL elements that the two 
paths — the advancement and the membership 
proof paths — have in common (see Lemma 7 in 
the appendix). 

Second, if two runs of the advancement veri- 
fication algorithm, applied to two different ad- 
vancement sequences, agree on the value of a 
particular AASL authenticator, then they must 
also agree on the authenticator values of all ear- 
lier AASL elements that the two advancement 
paths have in common (see Lemma 8 in the ap- 
pendix). 

Equipped with these two claims, we now 
tackle evolutionary collision resistance. 
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Theorem 3 (Evolutionary collision re- 
sistance of AASL membership proofs.). 

Consider two independent verifiers, A and B 
and a computationally constrained adversary 
who conveys to them independently two ad- 
vancement sequences. It is impossible for the 
adversary to produce advancement sequences 
and membership proofs in such a way that, first, 
the two verifiers, processing their respective ad- 
vancement sequences, advance to element po- 
sition n with the same digest T; and, second, 
the two verifiers, processing separate member- 
ship proofs, authenticate, at any time, two con- 
flicting membership claims. 

It is already known, from Theorem 2, that 
conflicting membership claims cannot be au- 
thenticated against the same authenticator. 
Here we address the case where the two aspir- 
ing proofs authenticate different data values for 
the same AASL position against the authenti- 
cators of different versions of that AASL held 
by the two verifiers. 

Let i be the element position for whose data 
element the adversary wishes to fool two ver- 
ifiers, A and B, and let j and k be the ele- 
ment positions against whose authenticators he 
wishes to produce the offending proofs for the 
verifiers; specifically, the adversary wishes to 
authenticate the membership claims {i,j,d) to 
A and {i, k, d') to B. Without loss of generality, 
we assume j<k, so 0<i<j<k<n. 

Consider the abstract illustration of this 
setup in Figure 4. ^'s advancement path, 
the dark dashed line, does not necessarily go 
through element i, but it certainly touches ele- 
ment j (since the adversary's membership proof 
is authenticated to A against the j-th authen- 
ticator) and element n (since the two verifiers 
agree on the value of the n-th authenticator). 
Similarly, B^s advancement path, the lighter 
dashed line, does not necessarily go through el- 
ement i, but certainly touches elements k and 
n. A^s membership proof path (the thick dark 
line) starts from i and ends at j, and B's mem- 
bership proof path (the lighter dark line) starts 
from i and ends at k. 

There is an element in [j,k], element m, 
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Figure 4: Illustration of the proof of Theorem 3. 
Verifier A advances to the n-th digest of the 
AASL via element j. When A held the j-th di- 
gest for the AASL, he had successfully authen- 
ticated a datum for the i-th position. Verifier 
B advances to the n-th digest of the AASL via 
element k. When B held the A;-th digest for 
the AASL, he had successfully authenticated a 
datum for the same i-th position as A did. 

that is common among yl's advancement path, 
B's advancement path, and H's membership 
proof path. This results from the fact that 
B^s membership proof and advancement paths 
both start before element j and touch element 
A;, and ^'s advancement path touches element 
j and continues past element k. An intuitive 
reason for this is that ^'s advancement path 
can skip element k only by "jumping" over it 
on a high-level linked list. Then, B's member- 
ship proof and advancement paths must touch 
the jumping-off point of ^'s path, on their way 
to "lower" k. We prove this claim rigorously in 
Lemma 5, in the Appendix. 

The two advancements agree on the value of 
T" after processing the respective advancement 
sequences in ProcessAdvancementProof, as 
per the theorem assumption. Because of 
the second authenticator agreement claim de- 
scribed above, this means that the two advance- 
ment algorithms also agree with each other on 
the value of T"^ after processing the correspond- 
ing part of their respective advancement se- 
quences that brings them both to element m. 

Because B's membership proof verification, 
to succeed, must agree on the value of 
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with the advancement verification algorithm, 
and because of the first authcnticator agree- 
ment claim above, the membership proof verifi- 
cation algorithm on B also agrees on the value 
of with B^s advancement verification algo- 
rithm after they both reach element m. There- 
fore, iB's membership proof verification algo- 
rithm and both advancement verification algo- 
rithms agree on the value of T"* after reaching 
element m. 

As above, there is an element in ele- 
ment r, that is common among ^'s advance- 
ment path, and A and B^s membership proof 
paths. This is because both membership proof 
paths start at i and go to or past j, and A^s 
advancement path starts before i and touches 
element j (since «4's membership proof must 
be verifiable against the digest for element j, 
as per the theorem assumptions). 

Because ^'s membership and advancement 
proof verification algorithms must agree on the 
value of for the membership proof to be ac- 
cepted, and from the first authcnticator agree- 
ment claim once more, the membership proof 
verification algorithm on A also agrees on the 
value of with ^'s advancement algorithm af- 
ter reaching element r. From the same claim, 
since B^s membership and ^'s advancement 
proof verification algorithms agree on the value 
of T"^ after reaching element m, they must also 
agree on the value of T'^' after they reach ele- 
ment r. As a result, the two membership proof 
verification algorithms reach element r with the 
same value for T^. 

However, this contradicts Theorem 2. If the 
adversary could manage to create two member- 
ship proofs starting with different data values 
on clement i and computing the same authcn- 
ticator for clement r, then he would be able to 
produce same-version collisions, as well, which 
Theorem 2 precludes. Therefore, the two data 
elements d and d' cannot be different. □ 

5 Conclusions 

In this work we describe, design and analyze the 
security of a tamper-evident, append-only data 



structure for maintaining secure data sequences 
in a loosely coupled distributed system, where 
individual system components may be mutually 
distrustful. The resulting data structure, called 
Authenticated Append- Only Skip List, allows 
its maintainers to produce one-way digests of 
the entire data sequence, which they can pub- 
lish to others as a commitment on the contents 
and order of the sequence. The maintainer can 
produce efficiently succinct proofs that authen- 
ticate a particular datum in a particular posi- 
tion of the data sequence against a published 
digest. 

AASLs are secure against tampering even by 
malicious structure maintainers. First, we have 
shown that a maintainer cannot "invent" and 
authenticate data elements for the AASL af- 
ter he has committed to the structure. Sec- 
ond, he cannot equivocate by being able to 
prove conflicting facts about a particular po- 
sition of the data sequence. This is the case, 
even when the data sequence grows with time 
and its maintainer publishes successive commit- 
ments at times of his own choosing. 

We have implemented and extensively mea- 
sured the performance and storage require- 
ments of AASLs (we present a discussion of 
practical implementation considerations in the 
Appendix). We have used AASLs extensively in 
Timeweave [5], a system for preserving historic 
integrity in trust-free peer-to-peer systems. 
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A The Need For Bases 

We give here a simple example of how "forget- 
ting" the values of reusable authenticators can 
allow a malicious maintainer to authenticate 
conflicting membership claims across AASL 
versions. Consider the authenticator for ele- 
ment 8, in Figure 5; it is used in all membership 
proofs verifiable against the digest of version 1 
ending with element 9, since the authenticator 
for element 9 depends on a single partial au- 
thenticator, that for element 8. However, the 
authenticator for element 8 is also used in all 
membership proofs verifiable against the digest 
of version 2 ending with element 10, because 
the authenticator for element 10 also depends 
on the authenticator for element 8 for one of its 
partial authenticators. 

A malicious maintainer can construct two au- 
thenticators and T^' for element 8 to ac- 
commodate two different elements ds and d'g, 
respectively, using Equations 1 and 2, as fol- 
lows: 

r« = /i(/i(8||o||4l|r^) II K8\\i\\d8\\T^) \\ 

/i(8||2||d8||T4) II /i(8||3||d8||T0)) 



/i(/i(8||0||4||T^) II ^(8||1||4||T^ 
hmnd'sWT') II M8||1||4I|T°)) 



He can then construct a single authenticator 
for element 9 based on T^': 

= h{h{9\mdg\\T^')) 

and use it to commit to version 1, which ends at 
element 9, with this and the first advance- 
ment proof A'^'^: 

= ((4; {T\T\T\T^)), (dg; (T^'))) 

The digest for version 1 authenticates do in 
position 8 with the following membership proof: 

^8,9,4 ^ ^^^/ . (^7,^^^^T0)), (dg; (r«'))) 

Now the malicious maintainer can construct 
a corrupt authenticator T^^ for the 10-th ele- 
ment, by mixing from the AASL that con- 
tains cig ill position 8, and T^, from the AASL 
that contains dg in position 8: 

T^o = /i(/i(io||o||dio||r9)||/i(io||i||dio||r8)) 




Figure 5: A repeat of Figure 3. An ex- 
ample of advancement in a dynamic AASL. 
In version 1, the AASL has elements 1 
through 9. The corresponding advancement is 
= ((4;(T^T^T^T0)),(d9;(^8))). Then 
the maintainer adds element 10 and pub- 
lishes version 2, with advancement A?'^^ = 
{{dio;{T^,T^))). The gray links delineate the 
traversal paths that the two advancements take. 



and publish it as the digest for version 2, with 
the corresponding advancement proof 

A^^'^ = {{dio;{T^T^))) 

In conflict to version 1, version 2 authenticates 
element dg in position 8, with the following 
membership proof: 

= ((4;(^^^^^^TO)),(dlo;(^^^8))) 

The problem lies in the verifler's forgetting 
that the value for the purported authentica- 
tor of element 8 was T^' in the first advance- 
ment A^'^ to version 1, whereas the same au- 
thenticator has the value ^ in the sec- 
ond advancement A^'^^ from version 1 to ver- 
sion 2. To avoid this problem, verifiers keep 
track of reusable authenticators, such as 
in the example above. With every advance- 
ment received, a verifier checks that any reused 
authenticators in the advancement agree with 
those known so far in the basis for the same 
AASL; then, the verifier updates that basis 
with any new reusable authenticators included 
in the newly received advancement. 
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B Algorithms 

Here we describe the proof construction algo- 
rithms in detail. They do not participate in 
any of the security proofs, since the security 
guarantees offered by AASLs have to do with 
what claims diligent verifiers accept. 

First, Algorithm 6, describes how individ- 
ual proof components are constructed. These 
proof components participate in both member- 
ship and advancement proofs. 

Algorithm 6 SingleProofComponent (j) 
C. Return a proof component C for the AASL ele- 
ment in position j. 

1: Tyec ^ {Authenticators.} 
2: for Z = to fj do 

4: end for 

6: Return C 



Then, we proceed by describing how a whole 

membership proof (Algorithm 7) and a whole 
advancement proof (Algorithm 8) are con- 
structed. 

Algorithm 7 ConstructMembershipProof 
(i,n) ^ E. Return a membership proof E for the 
i-th element of an AASL, verifiable against the n-th 
authcnticator, whore n > i. 

1: E ^ {The proof.} 

2: j <— i {Current element.} 

3: repeat 

4: C ^ SingleProofComponent (j) 
5: E^E\\C 

6: / ^ SingleHopTraversalLevel {j, n) 
7: j^j + 2' 
8: until j > n 
9: Return E 



C Proofs of Additional Claims 

In this appendix, we prove the intuitive claims 
we have used in the security analysis of the pa- 
per. 

First, we prove a claim necessary for 
the collision-resistance theorem (Theorem 2), 



Algorithm 8 ConstructAdvancementProof 
(i,n) A. Construct an advancement proof from 
the z-th authenticator of an AASL to the n-th au- 
thenticator, where n> i. 

1: {The proof.} 

2: j <— i {Current element.} 

3: while j < n do 

4: I ^ SingleHopTraversalLevel {j, n) 
5: 3^3 + 2' 

6: C SingleProofComponent (j) 
7: A^A\\C 
8: end while 
9: Return A 



showing that ProcessProofComponent is 
collision-resistant . 

Lemma 1 (Different proof components 
cannot yield the same authenticator). 

Consider two independent invocations of Pro- 
cessProofComponent with inputs (j, C) and 
{j',C') respectively. If the two invocations yield 
the same result T , then the inputs must he iden- 
tical (j = j' and C = C ). 

In both invocations. Line 10 must yield the 
same result T. Since h is collision resistant, the 
input P to the hash function must be the same 
across invocations. 

Input P is constructed in the loop of Lines 6 
- 9, by concatenating a hash result, produced in 
Line 7, to the running P in every iteration. To 
ensure that P is the same in both invocations, 
the loop must be iterated the same number of 
times (so as to construct P's of the same bit 
length), and all appended L-elements in the re- 
spective invocations must be identical. 

At every iteration of the loop. Line 7 com- 
putes the current L by hashing together the 
index j of the assumed AASL element to 
which the current proof component should cor- 
respond, the iteration number I (which is, by 
default, the same across invocations), the pur- 
ported data value of the j-th AASL element, 
and the Z-th authenticator value contained in 
the proof component. Again, due to the col- 
lision resistance of the hash function /i, the 
L values computed in the two invocations can 
be identical only if the input index j is equal 
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across invocations, and, similarly, if all parts 
of the input proof component C are respec- 
tively identical. This means that two invoca- 
tions of ProcessProofComponent for inputs 
(j, C) and {j',C') can yield the same T if and 
only if j = f and C = C'. □ 
As mentioned in the paper, second pre-image 
resistance is a corollary of the collision resis- 
tance theorem. 

Theorem 4 (AASL Membership Proof 
Second Pre-image Resistance). Consider 
a membership proof that verifies against 

authenticator T the membership claim {i,n,d), 
where < i < n, and d is a data value. A com- 
putationally bound adversary cannot construct 
efficiently a different membership proof E' veri- 
fiable against the same authenticator T that au- 
thenticates a conflicting membership claim. 

Suppose that an adversary can, in fact, con- 
struct efficiently such a second proof E' for the 
membership claim t' = {i,n',d'), where n ^ n' 
or d ^ d' . This means that he has an efficient 
way to construct collisions as well: he creates 
a legitimate AASL, picks a random position 
and constructs a membership proof E for it, 
then constructs another membership proof E' 
for a different data element in the same posi- 
tion. The two proofs would be a collision as 
defined in Theorem 2. However, we have al- 
ready shown that collisions are not possible, so 
the proof machinery must also be second pre- 
image resistant. □ 

Before we can prove the authenticator agree- 
ment claims, we must first establish that 
skip list traversal, as described by SingleHop- 
TraversalLevel, follows the rules of the skip 
list, specifically that both source and destina- 
tion of an /-level hop are divisible by 2' . 

Lemma 2 (Correctness of skip list traver- 
sal). In both advancement paths and member- 
ship proof paths, as accepted by the verifica- 
tion algorithms ProcessAdvancementProof 

am,d ProcessMembershipProof, respectively, 
every hop from element i to element j has 
length 2\ such that 2' divides both i and j. 



We prove this claim informally, by inspection 
of the corresponding algorithms. 

The path of an advancement is verified 
by ProcessAdvancementProof. The verified 
path starts with the source element i, given 
in the input parameters to the algorithm, and 
proceeds by increments of 2' in Line 7 inside 
the loop. The exponent I of the path length 
is determined by SingleHopTraversalLevel, 
given the current element j and the ultimate 
destination n of the advancement. 

Similarly, a membership proof path is veri- 
fied by ProcessMembershipProof. The path 
starts with the source element i where the ele- 
ment to be authenticated is claimed to reside in 
the input parameters. Then the path proceeds 
by increments of 2' in Line 5 for the first hop 
and Line 15 for all subsequent hops. Both lines 
receive their I from the result of SingleHop- 
TraversalLevel, given the current element j 
{i in the case of Line 5) and the ultimate desti- 
nation n of the membership proof. 

For both types of paths, it suffices to show 
that the I computed by SingleHopTraversal- 
Level is such that 2' divides j. Then it must 
also divide the destination j + 2K SingleHop- 
TraversalLevel uses as a fall-through selec- 
tion of / the value 0, which is consistent with 
the claim, since 2° = 1 divides all elements. 
When the loop in the algorithm is executed at 
least once, the variable L returned is always 
one that has passed the conditional check of 
the loop, that is, 2^ divides the source element 
j (called i in SingleHopTraversalLevel). 

We have shown that membership proof 
paths, and paths of single advancements sat- 
isfy the claim. For advancement paths of mul- 
tiple advancements the claim also holds, since 
connected advancements share an element: the 
earlier one ends where the later one begins. 
This means there are no additional hops in the 
resulting advancement path to those included 
in the individual advancements, which already 
satisfy the claim as we showed above. □ 

We continue by analyzing the concept of the 
basis. We use the two lemmata below in au- 
thenticator agreement. 
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Lemma 3 (Correspondence of bases to 
binary representations). Given the l-th 
AASL element, if the binary representation 
6fc6fc_i ... 60 of I has a in bit position i, then 
the corresponding basis vector B'^ has an empty 
value in vector position i, and a non-empty 
value otherwise. 

Bases arc changed only via ProcessAd- 
vancementProofComponent, so wc concen- 
trate on that to prove this lemma. We prove 
the lemma by induction on all AASL elements, 
and for every element on all hop lengths leading 
to that element. 

By definition, the base case holds, since 
has only empty values, just as the binary rep- 
resentation of has only O's. 

We assume that the lemma holds for all bases 
up to that of element — 1: that is, the basis 
vector for AASL element index m < k — 1 has 
an empty value in position I if and only if the 
binary representation of m has a in bit posi- 
tion /. We show that this must also hold for the 
basis B'^ that corresponds to element index k. 

Process AdvancementProofComponent 
yields the basis B^ for clement index k when- 
ever its input contains the source element 
index j and the hop level I and j = k — 2^ . 
ProcessAdvancementProof expects the out- 
come of such an invocation to be B^ = 5-'+^ 
in Line 6. 

There are fk + ^ ways in which ProcessAd- 
vancementProofComponent can be invoked 
to return B^, one for each different level I at 
which an advancement path reaches element k. 
This is because, as shown in Lemma 2, Line 5 of 
ProcessAdvancementProof can only return Is 
such that the source (and consequently the des- 
tination) of the level-i hop (computed in Line 7) 
is divisible by 2'. Since fk is the exponent of the 
largest power of 2 that divides k, as per Equa- 
tion 3, there are /fe -|- 1 invocations of Line 6 
that make variable j in Line 7 to take the value 
k. 

We consider invocations of ProcessAd- 

vancementProofComponent for all I such 
that <l < fk, where j = k - 2^ and B = BK 
All of the possible input bases B = B^ corre- 



spond to element indices j that precede fc, and 
result are covered by the inductive hypoth- 
esis, above. 

In the "then" branch of the conditional 
(Line 7), the previous AASL element index j 
had a in the Z-th bit position of its binary 
representation. By turning that to a 1 via 
assigning a non-empty value to the l-th basis 
vector element, we add 2' to the binary repre- 
sentation of j = — 2', and we therefore reach 
the binary representation for k. 

If, instead, the "else" branch of the condi- 
tional is executed, the previous basis vector 
must have had a non-empty value in its /-th 
position, and, as a result, the binary represen- 
tation of j must have had a 1 in the Z-th bit posi- 
tion of its binary representation. The algorithm 
places empty values in all vector positions from 
the l-th one upwards that contain non-empty 
values and sets to a non-empty value (the value 
of the carry variable) the first vector position 
m > I that it finds containing an empty value. 
This translates into zeroing out all 1 bits in the 
binary representation of j from the l-ih to the 
m — 1-st bit positions, and placing a 1 in the 
formerly m-th bit. Zeroing out a 1 bit in posi- 
tion p means subtraction by 2^, so the result of 
the operation is to add (2™ - ^^"^^ 2^ = 2') to 
the binary representation oi j = k — 2\ which 
again yields the binary representation of k. 

This proves the inductive step, and as a re- 
sult the lemma holds for all bases computed by 
ProcessAdvancementProofComponent. □ 

Lemma 4 (Survival of authenticators in 
a basis). Consider a portion of an advance- 
ment path that goes through elements e and 
e! = e + 2\ for non-negative integers e and I. If 
is the authenticator for element e computed 
by the advancement processing algorithm, after 
reaching that element, then the value for is 
preserved by the algorithm in the basis, and still 
regarded as that of during processing of ele- 
ment e'. 

Informally, this lemma claims that while pro- 
cessing intermediate hops between two elements 
that are successive multiples of 2\ the advance- 
ment verification algorithm remembers the au- 
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thenticator of the first multiple, and uses its 
value to check the correctness of the processed 
advancement component when it reaches the 
second multiple. 

Since both e and e' are divisible by 2', then 
in the binary representation of e, bits through 
at least I — 1 are all 0. Because of Lemma 3, all 
basis elements in positions through at least 
I — 1 must be the empty value. 

Case 1: e and e' are consecutive ele- 
ments in the advancement path. The ad- 
vancement path takes a single hop at level I 
from e to e'. To process this advancement hop, 

the verifier executes an iteration of the loop 
in ProcessAdvancementProof where the lo- 
cal variable j is equal to e and the level returned 
in Line 5 is Z. 

The value for was either passed as input 
Tprev to the algorithm, if this hop is the first 
in its advancement, or computed and stored 
in Tcur in the previous iteration of the loop in 
Line 8, and then copied to T^fev in Line 13. 

Trivially, therefore, the value of Tp^ev, which 
the algorithm regards as during the loop it- 
eration that starts with j = e, is passed as input 
to ProcessAdvancementProofComponent in 
Line 6 and checked for consistency in Line 10. 
This proves the claim for this case. 

Case 2: e and e' are not consecutive ele- 
ments in the advancement path. Leaving 

element e, the advancement path takes a hop at 
level p, where p < I. Therefore, during the in- 
vocation of ProcessAdvancementProofCom- 
PONENT that takes as input the basis of element 
e. Line 7 is executed. What the algorithm re- 
gards at the time as (passed to it in its input 
parameters) is placed in the ^i-th position of the 
basis. Since all vector positions up to position 
l — l contained the empty value before this mod- 
ification, is the last (indeed, the only) non- 
empty value in the newly created basis vector 
in positions through l — l. 

In what remains of the advancement path to 
e', the value for is always the last non-empty 
element in vector positions through l — l. This 



is the case right after advancement element e 
has been processed, as shown above. We use 
this fact as the base case of an inductive argu- 
ment. 

Assume that is the last non-empty value 
in the first / elements of the basis vector, and 
it occupies position q < I. From Lemma 3, 
the current element index is only divisible, at 
most, by powers of 2 up to 2^. This means that 
the next advancement hop, as determined by 
SingleHopTraversalLevel in Line 5 of Pro- 
cessAdvancementProof can only proceed by 
a hop of length that is a power of 2 up to 2^. 
This only changes the g + 1 least significant bits 
of the element's binary representation. There- 
fore, even if the "else" branch of the conditional 
in ProcessAdvancementProofComponent is 
executed, the value of T*^ is the last non-empty 
value before the l-th element of the basis, and 
as a result is pushed to a higher element posi- 
tion of the basis. 

The only advancement hop that can elimi- 
nate from the first / elements of the ba- 
sis is the last one, leading to e'. Then value 
occupies position (Z — 1) of the basis: we 
showed above there cannot be any non-empty 
values between itself and position I, and the 
value must be eliminated from the first I posi- 
tions of the basis, since e' is divisible by 2' and 
has no I's in its binary representation up to and 
including bit position l — l. 

This means that when element e' is reached 
by the advancement proof verification algo- 
rithm, the value for is in the basis, in po- 
sition l — l. This is the basis vector position in 
which the algorithm expects to find the value 
for during consistency checking in Line 12 of 
ProcessAdvancementProofComponent. In- 
deed, the last advancement proof component 
that is processed is the one corresponding to 
element index e', which has in the Z-th posi- 
tion among its included authenticators what 
the prover sent as ~^ = T^. Note that 
when Line 12 is executed and eliminates value 
from basis vector position Z — 1, the local 
loop variable c is equal to Z — 1. 

Consequently, we have shown that the claim 
holds for both possible cases of advancement 
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paths between e and e', which proves the 
lemma. □ 
The proofs for evolutionary collision resis- 
tance and for the authenticator agreement lem- 
mata rely heavily on common elements in 
membership or advancement proof paths. We 
proceed with two lemmata that examine the 
arrangement of common elements of parallel 
paths. First, we look at common elements of 
parallel paths, regardless of the path type (ad- 
vancement or membership proof). Then, we 
show that between two common elements in a 
membership proof and advancement path, the 
advancement path always takes shorter hops 
than the membership proof path. 

Lemma 5 (Common elements of parallel 
paths) . Let i and j be positive integers, such 
that i < j. 

1. Consider a path A that includes element i 
and continues to j or past it. There is at 
least one element in [i,j\ that is shared by 
A and every path that starts at or before i 
and includes element j. The last element 
on path A before j ( or j if it is in path A ) 
is such an element. 

2. (The mirror case) Consider a path A that 
starts at or before element i and includes 
element j. There is at least one element 
in [i,j] that is shared by A and every path 
that includes element i and continues to 
element j or past it. The first element on 
A after i (or i if it is in path A) is such an 
element. 

We prove only the first part of the lemma. 

The proof for the second part of the lemma is a 
trivial "mirror image" of the proof for the first 
part. 

If path A contains element j, then we are 
trivially done. 

Now, assume that path A does not contain 
element j, and consider Figure 6. Path A must 
be able to overshoot element j on its way from 
i to beyond j. For this to happen, path A must 
advance from its last element m before j (i.e., 
i < m < j) past j, by a hop of level I and 
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Figure 6: Two parallel, interleaved paths A and 
B. A contains i, but not necessarily j. B con- 
tains j but not necessarily i. The thick gray 
lines represent single hops, as picked by Sin- 
gleHopTraversalLevel. 

length 2', where 2' divides m, and j must not 
participate in any linked list at level I or higher 
(i.e., 2^ does not divide j). The end point of 
this hop is m -|- 2' > j. 

Suppose m is not the single common element 
among path A and every path that starts at 
or before i and includes element j. Then there 
must be a path B' that manages to overshoot 
element m on its way to j. For this to happen, 
path B' must advance to its first element n after 
m (i.e., m < n < j) past m, by a hop of level I' 
and length 2' , and element m must not partic- 
ipate in any linked list at level or higher (i.e., 
2' does not divide m). This means that I' > I, 
since m is divisible by 2'. If n participates in 
the linked list at level it must be divisible by 
2 and, result, also by 2'. However, that is 
impossible, since m<n<j<m + 2K 

Therefore, every path B that starts at or be- 
fore i and includes j must include element m, 
which also belongs to path A. □ 

Lemma 6 (Common elements of proof 
and advancement paths). // a membership 
proof path has two common elements e and e' 
with an advancement path, then every element 
in the proof path between e and e' is also shared 
by that advancem,ent path. 

Consider a membership proof path and an 
advancement path that share elements e and 
e > e', but share no other elements between 
them. 

To prove the lemma, we suppose that none of 
the proof elements between e and e' belong to 
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Figure 7: Proof and advancement paths be- 
tween their common elements e and e'. The 
thick gray hne indicates a single hop, as calcu- 
lated by SingleHopTraversalLevel. 

the advancement path (see Figure 7). We show 
below that this hypothesis leads to a contradic- 
tion. 

After common element e, the two paths di- 
verge. The membership proof takes a hop at 
level /, whereas the advancement takes a hop 
at a lower level I' < I. The advancement can- 
not take a hop at a level higher than that of 
the proof; if such a hop were available that 
did not overshoot e' , then the proof would have 
also taken it (see SingleHopTraversalLevel). 
Furthermore, the advancement cannot take a 
hop at the same level I as the proof, because 
that would make the two paths identical be- 
tween e and e', which contradicts the hypoth- 
esis that intermediate membership proof ele- 
ments do not belong to the advancement path. 
We call the next element on the advancement 
path p = e + 2^ , and the next element on the 
membership proof path q = e + 2^ 

Because of Lemma 5, there must be a com- 
mon element between the two paths in [p,q]- 
However, this contradicts the hypothesis that 
the two paths share no elements between e and 
e' . As a result, all membership proof elements 
between e and e' must also belong to the ad- 
vancement path. □ 

Finally, we prove the two authenticator 
agreement lemmata. 

Lemma 7 (Authenticator agreement be- 
tween a membership proof and an ad- 
vancement proof verification). If the mem- 
bership proof verification Algorithm 3 and the 
advancement verification Algorithm 5, given an 



advancement sequence and a membership proof, 
respectively, agree on the value of authenticator 
T"- for element n during their independent ex- 
ecutions, then they also agree on the authenti- 
cator value of every other earlier element e 
(e < n) that the advancement path and mem- 
bership proof path have in common. 

Let k be the number of common elements in 
the two paths up to element n, and n = ei > 
62 > . . . > efc the common elements, from last 
to first. We prove the lemma using induction 
on the common elements e^, by following back- 
wards Algorithms 3 and 5. 

The base case for ei holds from the lemma 
assumption, since ei = n. 

For the inductive step, we assume that the 
two algorithms agree on the value of We 
must show that the two algorithms also agree 
on the value of T^'+i when they process the cor- 
responding proof component to reach element 

When the two algorithms process their re- 
spective proof component to compute the com- 
mon T^' they use Equations 1 and 2. Specifi- 
cally, they both compute 

T'^ = ^(...||4J|...) 

= h{...\\hiei\\l\\di\\T''~^')\\...) 

by invoking ProcessProofComponent in 
Line 8 of ProcessMembershipProof and 
Line 8 of ProcessAdvancementProof. Since 
h is collision resistant, when the two algorithms 
process element Cj they must agree on the val- 
ues of all for every level I of linked lists 
in which element Cj participates. 

Consider what happens in the two paths be- 
tween elements e^+i and Cj. Common element 
ej+i must be the membership proof element im- 
mediately preceding ej, because of Lemma 6. 
Therefore, because of Lemma 2, = ej+i -|- 2^ 
for some non- negative I'. The advancement hop 
that arrives at e, must be at the same level I' 
or lower level. This is because a higher-level 
/" > /' hop would have taken the advancement 
path from e^+i to element ei+i+2'-' , which must 
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lie beyond Cj = ej+i + 2''. Therefore, the ad- 
vancement path between Cj+i and Cj fohows ei- 
ther a single hop of level I' and length 2' , which 
is identical to that followed by the membership 
proof path, or a sequence of shorter hops at 
levels lower then I' . 

Case 1: The advancement path is iden- 
tical to the membership proof path. The 

value for T'^'+i used to compute T^* in the 
two algorithms while processing element Cj is 
the same as that known by the algorithms 
while processing the previous element ej+i, 
from Line 10 of ProcessMembershipProof 
and Line 10 of ProcessAdvancementProof, 
which proves the inductive step. 

Case 2: The advancement path is not 
identical to the membership proof path. 

We must establish that the value of T'^'+i that 
ProcessAdvancementProof computes while 
processing element Cj+i is the same as that 
known while processing the next common el- 
ement Cj. This follows from Lemma 4, since 
elements ej+i and are successive multiples of 
2^ 

As a result, the value for T^'+i produced by 
the advancement verification algorithm while 
processing element ej+i is the same as the value 
for r^*+i used by the membership proof verifi- 
cation algorithm while processing element e,. 
This is the same value as that for T'^i+i pro- 
duced by the proof verification algorithm while 
processing element Cj+i, as seen in Line 10 of 
ProcessMembershipProof. This proves the 
inductive step. 

The inductive step holds for both possi- 
ble cases of advancement paths, and as a re- 
sult, the inductive argument holds, proving the 
lemma. □ 

Lemma 8 (Authenticator agreement be- 
tween two independent advancement 

paths) . // two invocations of the advancement 
verification Algorithm 5, given two advance- 

m,ent sequences, respectively, agree on the value 
of authenticator computed after reaching el- 
ement n during their independent executions, 



then they also agree on the authenticator value 
T'^ computed after reaching every other earlier 
element e (e < n) that the advancement paths 
have in common. 

This proof is similar in structure to that of 
the preceding lemma. 

Let k be the number of common elements in 
the two paths up to clement n, and n = ei > 
62 > . . . > Cfc the actual elements, from last 
to first. We prove the lemma using induction 
on the common elements e^, by following back- 
wards two invocations of Algorithm 5. 

The base case for ei holds from the lemma 
assumption, since ei = n. 

For the inductive step, we assume that the 
two algorithms agree on the value of T'^' , after 
reaching element e^. We must show that the 
two algorithms also agree on the value of T^'+i 
after they reach element e^+i. 

When the two algorithms process their re- 
spective proof component to compute the com- 
mon they use Equations 1 and 2. Specifi- 
cally, they both compute 

= h{...\\hieMdi\\T'^-'')\\...) 

by invoking ProcessProofComponent in 
Line 8 of ProcessAdvancementProof. Since 
h is collision resistant, when the two algorithm 
runs process element they must agree on the 
values of all T^*~^ , for every level I of linked 
lists in which element participates. 

Consider what happens in the two paths be- 
tween elements ej+i and Cj. 

Case 1: Element e^+i immediately pre- 
cedes element in both paths. Both 
paths advance from e^+i to Cj in a single hop at 
level I, of length 2^ 

As shown above, the two runs agree on the 
value of r^i~2 . Since — 2' = Cj+i, and from 
Line 10 of ProcessAdvancementProof, the 
value for T'^'+i while processing element Cj must 
be identical to the value that the two runs com- 
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pute for r^'+i after processing the advancement 
at the previous element Cj+i. 

Case 2: Element Cj+i does not immedi- 
ately precede element in at least one 
of the paths. The two paths merge from 
two different immediate sources to element 
on their way from element ej+i. Because of 
Lemma 2, for some non-negative integers < 
I < I' without loss of generality, the element 
immediately preceding Cj on the first path is 
p = ei — 2\ and on the second it is g = Cj — 2^ . 
Note that q < p. 

Lemma 5 guarantees that there must be a 
common element between the two paths in 
[q,p], since the first path starts at or before 
q and reaches p on its way to e^, whereas the 
second path starts at q and goes past p on its 
way to Cj. Since q is the element immediately 
preceding on the second path, it must be 
the common element that Lemma 5 anticipates. 
Therefore, Cj+i = q. 

Because of Lemma 4, both runs of the ad- 
vancement verification algorithm agree on the 
value of T^»+i after processing element e^+i and 
after reaching clement Cj. 

The inductive step holds for both possible 
cases of advancement path commonalities and, 
as a result, the inductive argument holds, prov- 
ing the lemma. □ 

D Implementation 

We implement authenticated append-only skip 
lists using Java. We focus here on a disk-based 
implementation, since it allows much larger 
data sequences than any memory-only imple- 
mentation can, as well as persistence in the face 
of machine reboots. 

An AASL is stored on disk as a linear file 
that consists of a preamble and a sequence of 
element entries, one for each element currently 
contained in the AASL. An element entry con- 
sists of a data section and an authenticator sec- 
tion. 

The data section primarily holds the datum 
stored in the associated AASL element. This is 



the datum that participates in the computation 
of authcnticators, as per Equations 1 and 2. We 
call this the sensitive datum. Every element in 
a single AASL has sensitive data of a constant 
length, which is set when the AASL is initially 
created. 

The data section of element entries may also 
contain an insensitive datum. This is also a 
fixed-length bit string. However, it does not 
participate in authenticator computations. In- 
sensitive data may be useful information to the 
maintainer, collocated with the sensitive data 
for access efficiency, that need not be authen- 
ticated to remote verifiers of the AASL. Since 
insensitive data do not participate in authen- 
ticator computations, they can be changed at 
will by the AASL maintainer unobtrusively to 
AASL verifiers. 

The authenticator section of an element entry 
contains the authenticator computed for that 
element. 

The preamble of the AASL file contains the 
lengths in bytes of the sensitive and insensitive 
data in element entries, and the element posi- 
tion of the last incorporated element into the 
AASL. 

An empty AASL contains exactly one ele- 
ment entry: the entry for element 0, which is a 
special entry. Element entry has inconsequen- 
tial sensitive and insensitive data. Only its au- 
thenticator is meaningful. This authenticator 
is a value from the result domain of the hash 
function used, and it is agreed upon among all 
users of the AASL in advance. 

Our implementation has a deviation from 
the abstract design of AASLs described in Sec- 
tion 3. We slightly modify how authenticators 
are computed for elements of odd indices, which 
only participate in a single linked list. For such 
elements we skip the outer hash operation de- 
scribed in Equation 2, from concatenated par- 
tial authcnticators to the actual authenticator 
of the element. Since odd elements have only a 
single partial authenticator, that single partial 
authenticator is sufficient to ensure the collision 
resistance of AASL digests, and can serve as the 
actual authenticator of the element. Further- 
more, since half of the element indices are odd. 
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this savings in computation can be significant 
compared to the overall computation required 
by AASL operations. 

Another implementation optimization in the 
implemented AASLs deals with authentica- 
tor redundancy in membership and advance- 
ment proofs. In the idealized algorithms 
ProcessMembershipProof and ProcessAd- 
vancementProof, authenticators computed 
for the previous proof component are com- 
pared against the corresponding authentica- 
tor included in the next proof component (see 
Lines 10 and 10, respectively). Since we com- 
pute these authenticators in the process of veri- 
fying membership and advancement proofs any- 
way, there is no need also to include them in the 
proofs themselves. Consequently, we skip such 
authenticators in the AASL implementation. 
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